COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	This is a collection of ideas on how to make use of
C00005 00003	To assemble programs into virtual space
C00008 ENDMK
C⊗;
This is a collection of ideas on how to make use of
the mapping facilities and the extended memory now
available on the pdp-11.  

We are currently close to using all of memory for the AL
runtime system.  It is roughly divided in this way:
0-14000		Kernel
14000-30000	AL free storage
30000--50000	Interpreter
50000--60000	Pseudo-code
60000-110000	Servo code
110000--130000	DDT symbols
130000-160000	DDT
160000-177777	I/O device registers

I would like to see a system which fragments the runtime into
something like overlays.  Each overlay could be seperately
assembled.  It would have a virtual space that looks like this:
0-1000		Kernel vector area
1000-30000	AL Free Storage
30000-144000	Code area
144000-160000	DDT symbols
160000--177777	I/O device registers

DDT itself would have a virtual address space of its own, and get
its symbols from whatever program was currently running when DDT
was invoked.  The kernel would also have its own virtual address space.

Real memory would be divided like this:
0	1000	vector area.  everyone has this mapped to 0
1000	20000	kernel.
20000	50000	DDT
50000	51000	unused
51000	110000	AL free storage.  all overlays have this mapped to 1000
110000	240000	first code area, with symbols at top, descending
240000	370000	second code area, with symbols at top, descending
370000	520000	third code area, with symbols at top, descending
I don't know where the device registers are constrained to reside.
To assemble programs into virtual space

A modification to PALX is needed that will keep the location counter
and the relocation constant distinct.  That way code can be generated
to be put it the second code area, but still think it is going into
1000-160000. 

A modification to the .BIN format is needed so that locations with 18
bits of addressing can be generated. 

A slight modification to 11TTY would be necessary to interpret the
new .BIN format. 

To call a procedure in a different code area. 

I suggest that each procedure which is to be global have an entry in
a small table in common low core (the free storage area) which gives
its code area (one byte suffices) and its relative address in that
area (one word).  All JSR PC,FOO which cross areas would be replaced
in source code by CALLD LFOO which would be a macro for something
like MOV LFOO,-(SP) EMT 21 and the kernel would use LFOO as a pointer
into this common table, discover where the user wishes to transfer
control, and reset the map appropriately.  The return address would
be set to a special place (also in low core) which holds another EMT
instruction.  This would enable the kernel to handle the return.  The
kernel would have to keep a stack of return address-code area pairs
for each process in order to handle everything right.  It would also
need to keep information in the process control block about the
current map for that process. 

Assumptions: The interface can load all of memory, there is some way
for 11TTY to initialize the memory map, DDT can be changed to deal
with processes in other map arrangements, same with the kernel.  How
powerful is the MTPD instruction and friends?